In 3GPP Release 12, SA and RAN standardization groups worked on a Group Communication Service Enabler for a Long-Term Evolution (GCSE_LTE) study item. See, for example, 3GPP TR23.768. GCSE_LTE may be a 3rd Generation Partnership Project (3GPP) feature for enabling application layer functionality to provide group communication over an Evolved Universal Terrestrial Radio Network (E-UTRAN). Furthermore, a group communication service may provide a mechanism for distributing the same content to multiple users in a controlled manner. As an example, the concept of group communications may be used extensively in the operation of classical Land Mobile Radio (LMR) systems used by public safety organizations. The primary use of a group communication service in LMR may be providing Push To Talk (PTT) functionality. Thus, a group communication service based on 3GPP architecture, using LTE radio technology, may enable PTT voice communications with comparable performance.
The group communication service may allow flexible modes of operation when the users and the environment they operate in evolve. For example, LTE may allow broadband communication. Thus, a group communication service may support voice, video, or more generally, data communication. Also, LTE may allow users to communicate with several groups at the same time in parallel, e.g., voice to one group, and different streams of video or data to several other groups. The users of the group communication service may be organized into groups and a user may be a member of more than one group.
3GPP TR 22.486 lists requirements for developing enablers, i.e., modular functions and open interfaces (e.g., a resource efficient distribution mechanism) that may be used to design group communication service. Some of the high level requirements may include the following: the ability to make use of the GCSE provided by the 3GPP, the ability to be enabled on a group member basis, the ability to provide a mechanism to indicate network support of GCSE to the User Equipment (UE), and the ability to indicate the network support of GCSE to the user. Other high level requirements may include the GCSE supporting various media such as conversational type communication (e.g., voice, video), streaming (e.g., video), data (e.g., messaging), or a combination of them. The system described in 3GPP TR 22.486 may have the ability to uniquely identify a GCSE group, and uniquely identify a group member within a GCSE group. It may provide a mechanism for sending a group communication to all receiver group members. The receiver group members of the GCSE group may be able to receive communications from the GCSE group via group communication. The system of 3GPP TR 22.486 may also be able to authorize a group member to become a transmitter group member. A transmitter group member may be able to transmit to a GCSE group that is a member of the GCSE group, with or without being a receiver group member. The interface between the GCSE client on the UE and the network may be an open interface, and the network may provide a third party interface for group communication. This may imply that the interface supports features such as charging and authentication/authorization. The system may also provide a mechanism for a group member that is not connected via a 3GPP network, to communicate in a group communication for a GCSE group that it may be a member of.
Some of the requirements for group management in a GCSE_LTE system may be the following. The system may provide a mechanism for the dynamic creation, modification and deletion of GCSE groups. Information associated with a GCSE group may be used by the system to identify the GCSE group, and to specify attributes that determine how the group can be changed and used. The information may be used, e.g., to indicate which group members may be authorized for administrative functions, and to determine whether the GCSE group can be relayed via a Proximity Service (ProSe). The system may also provide notification of the creation or deletion of a GCSE group to its group members. If authorized, a user may be able to request and receive a list of all the GCSE groups for which it may be a group member. A mechanism may be provided such that, if authorized, a user may modify information associated with a GCSE group, add or remove group members of a GCSE group, and/or create/delete a GCSE group. If authorized, a user may also be able to request and receive a list of group members of a particular GCSE group. If authorized, a user may request a notification of when specific group members or any group member(s) may be added to or removed from a particular GCSE group.
Furthermore, the system may provide a mechanism for remotely configuring a UE with GCSE related information. A transmitter group member may transmit a group communication for a GCSE group without knowledge of the identities of other GCSE group members. A group member may request to join or leave an established group communication. The system may provide a mechanism to setup, release, and modify a Multipoint Service (MuSe) with applicable parameters, e.g., Quality of Service (QoS) or priority. The system may also validate parameters received in the request to setup or modify a group communication based on a policy specified by the group's subscription information, e.g., it may check for QoS or priority. The system may provide the means for notifying the requesting entity of any updates in the status of an on-going group communication. A group member may be able to express an interest in receiving group communications when the GCSE group is used for group communication. The system may provide a mechanism for a receiver group member to receive a group communication in order to be able to accept, reject or ignore the group communication. The system may also provide a mechanism for a receiver group member receiving a group communication to be required to accept the group communication.
High Level Architecture for GCSE
Referring now to FIG. 2, there is shown a high level diagram of GCSE group communication architecture 200. An architecture such as GCSE group communication architecture 200 may be discussed in, e.g., 3GPP TR23.768.
Group communication architecture 200 may include an application layer, and a 3GPP Evolved Packet System (EPS) layer. The application layer may include GCSE Application Server (GCSE AS) 214. The 3GPP EPS layer may include MuSe function 210. MuSe function 210 may interface with 3GPP EPS entities (which may be discussed in TS 23.401) to provide MuSe functionality. The 3GPP EPS layer may also include MME 206, PGW 208, CGSE application server 214 as well as eNBs, SGWs and UEs 204.
The reference points GC1, GC2, GC3, GC4 and GC5 in group communication architecture 200 may be described as follows. GC1 may be a reference point between a GCSE application running in UE 204, and a GCSE application running in GCSE AS 214. It may be used to describe an application level signaling requirement to enable multipoint functionality for GCSE_LTE. GC1 may also enable session establishment, floor control usages, etc. GC2 may be a reference point between GCSE AS 214 and Multipoint Service (MuSe) function 210. It may be used to describe an interaction between GCSE AS 214 and MuSe function 210, which may be provided by the 3GPP EPS layer. GC3 may be a reference point between an E-UTRAN (eNB) and MuSe function 210. It may also be used to describe an interaction between the E-UTRAN and MuSe function 210, in order to achieve multipoint functionality that may be provided by the 3GPP EPS layer. GC4 may be a reference point between Mobility Management Entity (MME) 206 and MuSe function 210. It may be used to describe an interaction between MME 206 and MuSe function 210, in order to achieve multipoint functionality that may be provided by the 3GPP EPS layer. GC5 may be a reference point between Packet Gateway (PGW) 208 and MuSe function 210. It may be used to provide DL unicast service by MuSe function 210.
3GPP LTE Release 8 and/or 9 (LTE Rel-8/9) may support up to 100 Mbps in a downlink (DL), and 50 Mbps in an uplink (UL) for a 2×2 configuration. The LTE DL transmission scheme may be based on an Orthogonal Frequency Division Multiple Access (OFDMA) air interface.
LTE Rel-8/9 and/or Release 10 (collectively “LTE Rel-8/9/10”) systems support scalable transmission bandwidths (e.g., for purposes of flexible deployment, etc.). Such scalable transmission bandwidths may include, for example, bandwidths of 1.4, 2.5, 5, 10, 15 and 20 megahertz (MHz).
In LTE Rel-8/9 (and as applicable to LTE Rel-10), each radio frame may have a duration of 10 milliseconds (ms.), and consist of 10 subframes, each of which may be 1 ms. Each subframe may consist of two (2) timeslots of 0.5 ms. each. There may be seven (7) or six (6) Orthogonal Frequency Division Multiplexing (OFDM) symbols per timeslot. The seven (7) symbols per timeslot may be used with a normal cyclic prefix length, and the six (6) symbols per timeslot may be used with an extended cyclic prefix length. Subcarrier spacing for the LTE Rel-8/9 system may be 15 kHz. A reduced subcarrier spacing mode using 7.5 kHz may also be possible.
A Resource Element (RE) may correspond to one (1) subcarrier during one (1) OFDM symbol interval. Twelve (12) consecutive subcarriers during a 0.5 ms. timeslot may constitute one (1) Resource Block (RB). Therefore, with seven (7) symbols per timeslot, each RB may consist of 84 REs. A DL carrier can range from six (6) RBs up to one-hundred ten (110) RBs corresponding to an overall scalable transmission bandwidth of roughly 1 MHz to 20 MHz. Each transmission bandwidth, e.g., 1.4, 3, 5, 10 or 20 MHz, may correspond to a number of RBs.
A basic time-domain unit for dynamic scheduling may be one subframe, which may consist of two consecutive timeslots. This is sometimes referred to as an RB pair. Certain subcarriers of some OFDM symbols may be allocated to carry pilot signals in the time-frequency grid. A number of subcarriers at edges of the transmission bandwidth may not be transmitted in order to comply with spectral mask requirements.
In LTE Rel-8/9, and Rel-10, there may be a single Hybrid Automatic Repeat ReQuest (HARQ) process active in the UL, and a single HARQ process active in the DL. This may occur in a single carrier configuration where the network may assign the UE only one pair of UL and DL carriers (Frequency Division Duplexing (FDD)), or one time shared carrier for UL and DL (TDD), for a subframe
LTE Carrier Aggregation (CA)
LTE-Advanced with CA (LTE CA Rel-10) is an evolution for improving single carrier LTE data rates using, among other solutions, bandwidth extensions. With CA, a UE may transmit and receive simultaneously over a Physical Uplink Shared Channel (PUSCH) and a Physical Downlink Shared Channel (PDSCH) (respectively) of multiple serving cells. For example, up to four Secondary serving Cells (SCells) may be used in addition to a Primary serving Cell (PCell), thus supporting flexible bandwidth assignments up to 100 MHz. Uplink Control Information (UCI), which may include HARQ acknowledgment and/or non-acknowledgement (ACK/NACK) feedback, and/or Channel State Information (CSI), may be transmitted either on Physical UL Control Channel (PUCCH) resources of the PCell, or on PUSCH resources available for a serving cell configured for UL transmissions.
Control information for scheduling of PDSCH and PUSCH may be sent on one or more Physical Downlink Control Channel(s) (PDCCH). In addition to LTE Rel-8/9 scheduling using one PDCCH for a pair of UL and DL carriers, cross-carrier scheduling may also be supported by a PDCCH. This may allow the network to provide PDSCH assignments, and/or PUSCH grants for transmissions in one or more other serving cells.
For FDD LTE Rel-10 UE operating with CA, there may be one HARQ entity for each serving cell. Each HARQ entity may have up to 8 HARQ processes, e.g., one per subframe for one Round Trip Time (RTT). Further, for an FDD LTE Rel-10 UE operating with CA, there may be more than one HARQ process active for the UL and for the DL in a subframe, but there may be only one UL and one DL HARQ process per configured serving cell.